As users of mobile wireless devices (e.g., smartphone, mobile phone, tablet computer, etc.) change their point of attachment in the cellular network (by movement or migration away from a cell tower of a cell region) and start getting served by a new edge-of-network application aware proxy server or “EdgeApp” server, the state in the edge app proxy/server associated with the mobile user might need to be migrated from an old EdgeApp server at the source node to a new EdgeApp server at a destination node.
FIG. 1 shows the current infrastructure 10 for handling phone call handoff (communication connection characteristics) and mobile application state handoff. The cellular network 10 includes a first (source) cell tower A (or base station) having edge of network components, e.g., a proxy server 20a, that is functioning as the cell that the mobile device 12 is in current communications over path 21. The EdgeApp proxy server 20a may reside at a web-site, or a cloud) at the cellular network infrastructure 10. The network 10 further includes a second (destination) cell tower B (or base station) having edge of network components, e.g., an application-aware “EdgeApp” server or proxy server 20b. As known in the art, as the mobile device 12 moves out of communications range with first base station A, the cellular network enables the second base station B in another geographical area to maintain the communications session with the mobile device 12, e.g., over a new communications path 22. That is, functionality is inherent in cellular network 10 to maintain a current communications session between the mobile 12 and the cell tower B as the mobile exits an area 15a serviced by the first (source) tower A and enters into an area 15b serviced by the cell tower B, in a seamless manner.
To effect the seamless transition, cellular network infrastructure 10 includes further network communications nodes or elements including a Radio Network Controller devices (RNC) 25A, 25B associated with cell Base stations A and B, respectively, in a “3G” wireless network, provide control and management of the radio transceivers in the cell node (base transceiver station) equipment, as well as perform management tasks like soft handoff. Additional network components include radio and gateway/router devices including the Serving GPRS (General Packet Radio Service) Support Node (SGSN) 23 which handles all packet switched data within the network, e.g., the mobility management and authentication of the users, and relays the data between the SGSN and a relevant Gateway GPRS Support Node (GGSN) 27 which is the IP access point for mobile users to the wider internet, corporate VPN or other IP access networks. Users attach to the network using a PDP (Packet Data Protocol) context activation, once they have been validated and authorized by the SGSN an IP connection is established to the GGSN and allowed services can then be accessed. In an example implementation, when the GGSN 27 receives data addressed to a specific user, it checks if the user is active. If it is, the GGSN forwards the data to the SGSN 23 serving the mobile user, but if the mobile user is inactive, the data are discarded. The operator services network component 30, e.g., a cloud or data center for cellular network operations that provides those wireless communications services for providing mobile user connectivity with the Internet 50 and controls all the elements necessary to sell and deliver services to an end user including radio spectrum allocation, wireless network infrastructure, back haul infrastructure, billing, customer care and provisioning computer systems and marketing.
In the conventional cellular network infrastructure 10, functionality inherent to the base station EdgeApp proxy servers 20a, 20b further maintains any state of an application being run by users on their mobile devices 12. More particularly, mobile device 12 includes one or more applications for communicating (e.g., communications applications components) and mobile (user) applications, e.g., video display, voice recognition, etc. It is a trend that these mobile applications increasingly communicate with the base station EdgeApp proxy servers 15a, 15b. For example, a mobile device 12 with a voice activation may include a voice recognition function at the cellular network itself at an EdgeApp server 20a,b. As a further example, a video display application on the mobile device communicates with a proxy inside the cellular network that may provide the content in a format for use by the particular mobile 12. A current trend in the art is for application service providers to “push” these mobile application proxy server components closer to the network “edge”, i.e., place the application components closer to the network proxy server side components including application components, as close as possible to the mobile client (i.e., close to the cell tower, for example) to save bandwidth, minimize communication latency, and off-load functionality. These close to edge of network applications are referred to herein as “EdgeApps”. Further, the EdgeApp server maintains state data including, but not limited to: communication state (e.g., connection characteristics) or pre-cached content (media files or web pages) all of which may need to be migrated to another node in order to achieve certain level of QoS for a roaming mobile user. This is migrated from one EdgeApp server to another as the mobile device migrates and is serviced by new nodes.
Currently, as mobile device 12 users change their point of attachment in the cellular network and commence being served by a new EdgeApp server (see FIG. 1), the state in the edge app proxy server associated with the mobile user might need to be migrated from old EdgeApp server (e.g., proxy server 20a) to new EdgeApp server (e.g., proxy server 20b) in order to maintain providing continuous uninterrupted service (e.g. state: connection characteristics) and to continue providing same level of quality of service (e.g. state: pre-cached objects that will be served fast from EdgeApp proxy/server). Currently, the EdgeApp proxy/server needs to be designed and architected so as to support such functionality (handoff and state-migration awareness) enabling state transfer, e.g., according to network controlled, or mobile device controlled techniques, for example.
That is, currently, the EdgeApp/Proxy server are designed and architected so as to explicitly support such functionality (referred to as: hand-off and state-migration awareness) and either uses a cluster-based design, which increases complexity or employs a specific protocol (e.g. multicast) for disseminating that state to multiple other EdgeApp servers. That is, migration aware functionality (multicast, migration-awareness, cluster-based architecture) proxy server has to be aware of migration actions to provide seamless transition to users. Unless EdgeApp/Proxy server provides migration aware services, the system may not be able to meet the QoS or QoE service guarantees. In addition, legacy application proxy software that has not been designed to explicitly support migration of mobile users cannot provide the full benefits while being deployed at the edge of the network.
It would be highly desirable to provide a generic approach for EdgeApp proxies/servers for roaming users without explicitly requiring handoff support by them.